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Who 


• Chris Valasek (@nudehaberdasher) 

— Sr. Research Scientist 

— Coverity 

• Tarjei Mandt (@kernelpool) 

— Vulnerability Researcher 

— Azimuth Security 
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What 


• Windows 8 Release Preview 

• Heap manager specifics 

• Exploitation techniques for Windows 8 heap 

• Prerequisite reading 

— "Understanding the LFH" 

• http://illmatics.com/Understanding the LFH.pdf 

• http://illmatics.com/Understanding the LFH Slides.pdf 

— "Modern Kernel Pool Exploitation" 

• http://www.mista.nu/research/kernelpool infiltrate2011.pdf 

— Kostya, Hawkes, Halvar, McDonald, Moore, etc 
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Why 


• Learn how the Heap Manager and Kernel Pool 
Allocator work (in detail) 

— PLEASE read the paper if you want full details, this 
presentation just touches the surface 

• Heap exploits that worked on Windows 7 will 
most likely NOT work on Windows 8 

• Let's find out why 
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User Land Back-End 
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Windows 8 Back-end 


• Slightly modified version of the Windows 7 
back-end [RtlpAllocateHeapO] 

• Mitigations 

1. Freeing of _HEAP structures is prohibited 
(R.I.P Ben Hawkes tech) 

2. Virtually allocated chunks now have randomized 
locality/size 
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Windows 8 Back-end (cont.) 
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Back-end Mitigation I 


• Prevents the freeing and subsequent allocation of a _HEAP 
structure in RtlpFreeHeapQ. 

— https://www.lateralsecurity.com/downloads/hawkes ruxcon-nov- 

2008.pdf 

- Although the direct overwriting can still occur, it is unlikely 

• Same holds true for RtlpReAllocateHeapQ 
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Back-end Mitigation I (cont.) 


RtlpFreeHeap(_HEAP *heap, DWORD flags, void *header, void *mem) 

{ 


if(heap == header) 

{ 

RtlpLogHeapFailure(9, heap, header, 0, 0, 0); 
return 0; 

} 


1 
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Back-end Mitigation II 


Chunk that exceeds the VirtualMemoryThreshold will be 
serviced by NtAllocateVirtualMemoryQ 

Previously, the allocations occurred with a potential for semi- 
predictable locations and sizes 

Changes have been made to add a random offset to the base 
address when allocating large chunks in RtlpAllocateHeapO 

Hope to encapsulate virtual chunk in inaccessible memory 
(MEM_RESERVE) 

Note: If safe-linking fails the application will only terminate if 

HeapTerminateOnCorruption has been set via 
HeapSetlnformation(), otherwise the chunk is NOT linked in 
but still RETURNED 
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Back-end Mitigation II 


//VirtualMemoryThreshold set to 0X7F000 in CreateHeapQ 
int request_size = Round(nequest_size) 
int block_size = request_size / 8; 
if (block_size > heap->VirtualMemoryThreshold) 

{ 

int rand_offset = (RtlpHeapGenerateRandomValue32() & 0xF) << 12; 
request_size += 24; 

int negion_size = request_size + 0x1000 + nand_offset; 

void *vintual_basej *virtual_chunk; 

int protect = PAGE_READWRITE; 
if (heap->flags & 0x40000) 

protect = PAGE_EXECUTE_READWRITE; 

//Attempt to reserve region_size bytes of memory 

if (NtAllocateVirtualMemoryC-lj &virtual_basej 0 , &region_sizej MEM_RESERVE, protect) < 0) 
goto cleanup_and_return; 

virtual_chunk = virtual_base + rand_offset; 

if (NtAllocateVirtualMemory(-lj &virtual_chunkj 0 , &request_size., MEM_COMMITj protect) < 0) 
goto cleanup_and_return; 

//XXX Set headers and safe link-in 

return virtual_chunk; 

} _ 
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User Land Front End 
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Windows 8 Front-End 


• Major changes to allocation and free 
algorithms and moderate changes to integral 
data structures 

• RtlpLowFragHeapAllocFromContextO will not 
be a "matched function" by BinDiff between 
Windows 7 and Windows 8 

• Mostly the same data structures but offsets 
and members have changed a bit 
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Windows 8 Front-End Mitigations 

• Mitigations 

1. Front-End Activation 

• Dedicated counters/index instead of ListHint->BIink 

• FrontEndHeapUsageData[] (See paper) 

2. Front-End Allocation 

• FreeEntryOffset removed 

• Non-deterministic allocations 

3. Fast Fail 

• RtlpLowFragHeapAllocFromZoneO implements fast fail 
- Also additional checking compared to Windows 7 

4. Guard Pages 

5. Arbitrary Free Mitigation 

6. Exception Handling Removal 
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Windows 7 Front-End 



_INTERLOCK_SEQ.Hint (i.e. FreeEntryOffset) is gathered 
from the free chunk w/o validation 
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Windows 7 Front-End Allocation 0 


UserBlocks 




<User Data> 


<User Data> 


<User Data> 




<User Data> 


<User Data> 


<User Data> 




<User Data> 


<User Data> 


<User Data> 




<User Data> 


<User Data> 


<User Data> 


Depth = oxoF 
FreeEntryOffset = oxo 



BUSY 
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Windows 7 Front-End Allocation I 


UserBlocks 



Depth = oxoE 
FreeEntryOffset = 0x06 



BUSY 
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Windows 7 Front-End Allocation 


UserBlocks 



Depth = oxoD 
FreeEntryOffset = oxoC 



BUSY 
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Windows 7 Front-End Allocation III 


UserBlocks 



<User Data> 


<User Data> 


<User Data> 


Depth = oxoC 
FreeEntryOffset = 0x12 



BUSY 
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Windows 8 Front-End 



+0x0008 

STRUCT 

{ 

UINT8 Sizeindex; 

UNIT8 GuardPagePresent; 
UINT16 PaddingBytes; 


+OxOOOC ULONG32 Signature 



No need to use the FreeEntryOffset as the Bitmap does all the work 


EntiyOffset w/in the UserBlocks I 
kept in _HEAP_ENTRY.PreviousSize 


r-1 

UserBlocks 


_ENTRY 

<User Data> 


_ENTRY 

<User Data> 


.ENTRY 

<User Data> 


.ENTRY 

<User Data> 
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Windows 8 Randomization 


• RtlpLowFragHeapRandomData initialized from 
RtlpCreateLowFragHeap and Slotlndex is updated on 
_HEAP_SUBSEGMENT creation [RtlpSubSegmentlnitialize()] 


RtlpInitializeLfhRandomDataAnnay() 

{ 

int Randlndex = 0; 
do 
{ 

//ensure that all bytes are unsigned 

int newrandl = RtlpHeapGenerateRandomValue32() & 0X7F7F7F7F; 
int newrand2 = RtlpHeapGenerateRandomValue32() & 0x7F7F7F7F; 

RtlpLowFragHeapRandomData[RandIndex] = newrandl; 
RtlpLowFragHeapRandomData[RandIndex+l] = newrand2; 

RandIndex+=2; 

} 

while(RandIndex < 64) 

} _ 
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Windows 8 Front-End Allocation 0 



oxo oxF 


FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 
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Windows 8 Front-End Allocation I 



Depth = oxoE 


FREE 


BUSY 


Start = RandRand(o, Bitmap.SizeofBitmap); 
Index = CicularSearch(Bitmap, Start) 
UpdateBitmap(Bitmap, Index) 

Return UserBlocks[Index] 


Index = 0x5 


oxo oxF 


FREE 

FREE 

FREE 

FREE 

FREE 

BUSY 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 
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Windows 8 Front-End Allocation II 



Depth = oxoD 


FREE 


BUSY 


Start = RandRand(o, Bitmap.SizeofBitmap); 
Index = CicularSearch(Bitmap, Start) 
UpdateBitmap(Bitmap, Index) 

Return UserBlocks[Index] 


Index = oxE 


oxo oxF 


FREE 

FREE 

FREE 

FREE 

FREE 

BUSY 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

BUSY 

|free 
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Windows 8 Front-End Allocation III 



Depth = oxoD 


FREE 


BUSY 


Start = RandRand(o, Bitmap.SizeofBitmap); 
Index = CicularSearch(Bitmap, Start) 
UpdateBitmap(Bitmap, Index) 

Return UserBlocks[Index] 


1 st Try => Index = 0x5 
Next => Index = 0x6 

0X0 oxF 


FREE 

FREE 

FREE 

FREE 

FREE 

BUSY 

BUSY 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

FREE 

BUSY 

|free 
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Win 7 vs Win 8 Allocation 


• Windows 7 

— Will sequentially allocate chunks from the UserBlock 

— No validation of FreeEntryOffset, hence it can be 
overwritten and used as an exploitation primitive 

• Windows 8 

- Randomized array used to search a bitmap 

— Bitmap will select the chunk, update itself and use a 
different random location each time 

— Heap determinism goes down significantly 

— FreeEntryOffset no longer kept in user data, therefore 
FreeEntryOffset Overwrite technique has died © 
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Windows 8 Front-End Mitigation III 


• Fast Fail 

- INT 0x29 Interupt 
— Designed to ensure 'fast failing' 

• http://www.alex-ionescu.com/?p=69 

— Search "CD 29" (x86) and find instances all over 
ntdll.dll 

— Only one assertion in the LFH, otherwise use the 
RtlpLogHeapFailureQ function and rely upon 
HeapTerminateOnCorruption flag 
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Windows 8 Front-End Mitigation III 

• Bad News: Windows 8 checks LFH->SubSegmentZones 


_HEAP_SUBSEGMENT *RtlpLowFragHeapAllocateFromZone(_LFH_HEAP *LFH, int Affinitylndex) 

{ 


_LIST_ENTRY *subseg_zones = &LFH->SubSegmentZones; 
if (LFH->SubSegmentZones->Flink->Blink != subseg_zones || 

LFH->SubSegmentZones->Blink->Flink != subseg_zones) 
_asm{int 29}; 

> _ 


• Good News: Windows 7 has less strict checks 

- Potential for write-4 primitive © 
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Windows Front-End Mitigation IV 


• Guard Pages were added between 
_HEAP_USERDATA_HEADER objects to foil 
overwrites and heap spraying 

• Therefore, an overflow will need to exist in the 
same UserBlock, potentially guarding other 
UserBlock containrs. 

• After a certain amount of chunks exist for a 
certain size a guard page will be added for 
subsequent UserBlock creations 

• If page_shift == 0x12 11 total_blocks >= 0x400 
- Add a guard page to the allocation 
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Windows Front-End Mitigation IV 


RtlpLowFragHeapAllocFromContext() 

{ 


//determine if we should use a guard page 
set_guard = false; 

//The total amount of chunks available for a _HEAP_SUBSEGMENT 
int total_block = HeapLocalSegInfo->Counters.TotalBlocks; 
if (total_blocks > 0x400) 

total_blocks = 0x400; 

//there are other operations here, left out for brevity 
int page_shift = 7; 

int req_size = total_blocks * RtlpBucketBlockSizes[HeapBucket->SizeIndex] + 8; 
req_size = req_size + Round32(total_blocks) + 0x24; 
do 

page_shift++; 

while(req_size >> page_shift); 


if (page_shift == 0x12 || total_blocks >= 0x400) 
set_guard = true; 

//will allocate memory for the UserBlocks and add a guard page if necessary 
RtlpAllocateUserBlock(LFH, page_shift, BucketByteSize, set_guard); 


} 
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Windows Front-End Mitigation IV 


RtlpAllocatellserBlock calls RtlpAllocateUserBlockFromHeap 

RtlpAllocateUsenBlockFromHeap(_HEAP *heap, int size, bool set_guand) 

{ 


_HEAP_USERDATA_HEADER *user_block = RtlAllocateHeap(heap, 0x800001, size - 8); 
if (set_guand) 

{ 

int page_size = 0x1000; 

//get the page aligned address then caluculate the size 
//plus one page (0x1000) 

int page_end_addr = (user_block + (size - 8) + 0xFFF) & 0xFFFFF000; 
int new_size = page_end_addr - user_block + page_size; 

//reallocate with an additional page of memory appended 

user_block = RtlReAllocateHeap(heap, 0x800001, user_block, new_size); 

//make the last page of this memory PAGE_NOACCESS 

ZwProtectVirtualMemory(-1, &new_size, &page_size, PAGE_NOACCESS, Soutput); 
user_block->GuardPagePresent = true; 

} 

return user_block; 


azimuth 


Windows 8 Heap Internals 


coverity' 


Windows Front-End Mitigation IV 

Low Address 


Overflow 

Direction 


Contiguous 

Memory 


Higher Address 


UserBlocks l for _HEAP_BUCKET[ox6] 

Guard Page [PAGE_NOACCESS] 

UserBlocks l for _HEAP_BUCKET[ox8] 

Guard Page [PAGE_NOACCESS] 

UserBlocks 2 for _HEAP_BUCKET[ox6] 
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Windows Front-End Mitigation V 


• Ben Hawkes devised a technique to turn an overwrite of a LFH 
chunk into a semi-arbitrary free 

- https://www.lateralsecuritv.com/downloads/hawkes ruxcon-nov- 

2008.pdf 

- Overwrite 'Flags' and 'Index' to point at a valid chunk within the 
UserBlock 

- Therefore you can taint a overflowed header, point to a legitimate, in- 
use chunk and free it 

- Win! 

• There are checks to ensure that this will no longer work © 
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Windows Front-End Mitigation V 


RtlFreeHeap(_HEAP *Heap, DWORD Flags, void *Mem) 

{ 


//if the header denotes a different segment 
//then adjust the header accordingly 
_HEAP_ENTRY *header = Mem - 8; 
if (Mem - 1 == 0x5) 

header -= 8 * header->SegmentOffset; 

if (!(header->UnusedBytes & 0x3F)) 

{ 

//this will prevent the chunk from being freed 
RtlpLogHeapFailure(8, Heap, header, 0,0,0); 
header = NULL; 

} 


} 
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Windows Front-End Mitigation V 


if(Mem - 1 == 0x5) 

{ 

//this chunk was from the LFH 
if (header->UnusedBytes & 0x80) 

{ 

//ensures that the header values haven't been altered 

if( ! RtlpValidateLFHBlock(Heap, header)) 

{ 

RtlpLogHeapFailure(3, Heap, header, Mem, 0, 0); 
return 0 ; 

} 

} 

} 
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Windows 8 Front-End Mitigation VI 


• Windows 7 wrapped 

RtlpLowFragHeapAllocFromContextO in a 

try/catch that would handle any exception 

• I've speculated that this could be used to 
'brute force' address overwrites if multiple 
memory corruptions were a possibility. 

• This is REMOVED in Windows 8 © 
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Summary 


Primitive 

Windows Vista 

Windows 7 

Windows 8 (RP) 

Heap Handle Protection 

n 

0 

0 

Virtual Memory 
Non-Determinism 

n 

0 

0 

FrontEndStatusBitmap 

n 

0 

0 

LFH Non-Determinism 

n 

0 

0 

Fast Fail 

0 

0 

0 

Guard Pages 

0 

0 

0 

Arbitrary Free Protection 

0 

0 

0 

Exception Handler 
Removal 

0 

0 

0 
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User Land Exploitation Tech 
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Bitmap Flipping 2.0 


• A LFH chunk's index within the UserBlock is still kept in an un¬ 
encoded fashion 

- _HEAP_ENTRY.PreviousSize 

— Used to update the UserBlock->Bitmap 

• bittestandreset(UserBlocks->BusyBitmap->Buffer, header->PreviousSize); 

- Zero out certain bits relative to the address of the BusyBitmap 

- PROBLEMS 

• The UserBlock is taken from the _HEAP_SUBSEGMENT 

• SubSegment derived from chunk header 

• SubSegment = *(DWORD)header A (header / 8) A heap A RtlpLFHKey; 

• UserBlocks = SubSegment->UserBlocks; 

• Corruption the chunk header (via sequential overflow) will wreck the SubSegment 
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Bitmap Flipping 2.0 


BusyBitmap.Size = 0x4 


_HEAP_ENTRY BAD 

_HEAP_ENTRY 

_HEAP_ENTRY 

_HEAP_ENTRY 


_HEAP_ENTRY 

_heap_entry 

_HEAP_ENTRY 

_HEAP_ENTRY 

UserBlocks 

Chunks 

_HEAP_ENTRY 

_HEAP_ENTRY 

_HEAP_ENTRY 

_HEAP_ENTRY 

J 


By making the PreviousSize of a chunk header to free larger 
than BusyBitmap.Size, an attacker can NULL out bits. 
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HEAP USERDATA HEADER Attack 


Attack the new _HEAP_USERDATA_HEADER structure 
(aka UserBlocks) 

Has a member called BlockStride, which denotes the amount of space 
between each chunk 

- Also FirstAllocationOffset can be targeted as well 

Used to return the proper chunk to the calling application 

- Chunk = UserBlocks + Randlndex * BlockStride + FirstAllocationOffset 
Effectively the same as Windows 7 Free Entry Offset overwrite 
PROBLEMS 

- Guard pages if too many allocations are made of the same size 

• Stagger allocation sizes [i.e. alloc(0x40) x 10; alloc(0x48) x 10, etc) 

- You have to position your overflow-able chunk BEFORE a 
_HEAP_USERDATA_HEADER structure (which can be challenging) 

- Tainting the _RTL_BITMAP structure could cause more instability 

- if ((ret_chunk->Unused Bytes & 0x3F)) 

• RtlpLogHeapFailureQ 
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HEAP_USERDATA_HEADER Attack 

_HEAP_USERDATA_HEADER 

r - A 


Memory 

Chunks 


+0x0000 - SubSegment +0x0004 - Reserved +0x0006 - SizelndexPadding +0x000C - Signature 



FirstANocationOffset 0x0012 - BlockStnde 

+0x0014 - BusyBitmap +0x001C - BitmapData 

HEAPENTRY 

HEAPENTRY 

_HEAP_ENTRY 

HEAPENTRY 

HEAPENTRY 

HEAPENTRY 

+0x0000 - SubSegment +0x0004 - Reserved 

+0x0008 - SizelndexPadding +0x000C - Signature 

FirstAMocationOffset 0x00t 2 .Bi.okStrtd. 

+0x0014 - BusyBitmap +0x001C - BitmapData 

_HEAP_ENTRY 

_HEAP_ENTRY 

_HEAP_ENTRY 

_HEAP_ENTRY 

_HEAP_ENTRY 

HEAPENTRY 


Contiguous 

Memory 
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HEAP_USERDATA_HEADER Attack 

_HEAP_USERDATA_HEADER 


Overflow 

Direction 

\/ 


+0x0000 - SubSegment +0x0004 - Reserved +0x0006 - SizelndexPadding +0x000C - Signature 


SSSS8SS 0x0012 -BlockStrfde 

+0x0014 - BusyBitmap +0x001C - BitmapData 

HEAPENTRY 

_HEAP_ENTRY 

_HEAP_ENTRY 

_HEAP_ENTRY 

_HEAP_ENTRY 

_HEAP_ENTRY 

+0x0000 - SubSegment +0x0004 - Reserved 

+0x0008 - SizelndexPadding +0x000C - Signature 

0x0010 - FirstAllocationOffset 0x0012 -BlockStride 

+0x0014 - BusyBitmap +0x0010 - BitmapData 

HEAPENTRY 

_HEAP_ENTRY 

_HEAP_ENTRY 

_HEAP_ENTRY 

HEAPENTRY 

HEAPENTRY 




Contiguous 

Memory 
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Kernel Pool 
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Kernel Pool 


• Deterministic allocator 

— First chunk allocated from top of page 
— Subsequent chunks allocated bottom-up 

• Uses traditional doubly linked free lists 

— Ordered by block size 

• Focused on efficiency 

— Uses lookaside lists for small chunks 

• Used by drivers and system components 
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Pool Types 


• Generally two types of pool memory 

• Non-paged pool 

— Guaranteed to be present at any time 
— Can be accessed by any code, regardless of IRQL 

• Paged pool 

— Can be paged out 

— Can only be accessed at IRQL < DPC/Dispatch level 
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Pool Descriptor 


• Each pool is managed by a pool descriptor 

• Primarily manages lists of free pool chunks 

— Ordered by block size 

• x86: 8 bytes 

• x64:16 bytes 

— Used for allocations up to 4080 bytes 

• Also keeps track of no. of allocations/frees, 
pages in use, etc. 
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Pool Header 


• Each pool chunk is preceded by a pool header 

— Defines size of previous/current chunk, pool type, 
associated pool descriptor and process pointer 

• kd> dt nt! POOL HEADER 


— +0x000 PreviousSize 

— +0x000 Poollndex 

— +0x000 BlockSize 

— +0x000 PoolType 

— +0x004 PoolTag 

— +0x008 ProcessBilled 


: Pos 0, 8 Bits 
: Pos 8, 8 Bits 
: Pos 16, 8 Bits 
: Pos 24, 8 Bits 
: Uint4B 

: Ptr64 EPROCESS 
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Windows 8 Kernel Pool 
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Windows 8 Kernel Pool 


• Hardened version of the Windows 7 kernel pool 

— No significant structure changes 

• Includes a lot more checks 

— Pool header validation (e.g. Poollndex) 

— Linked list validation 
— Cookies used to protect pointers 

• Introduces the non-executable pool 

— Designed to thwart spraying of executable kernel code 
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NX Pool 


• Windows 8 introduces the non-executable 
(NX) non-paged pool 

— New pool type: NonPagedPooINx (0x200) 

— Most non-paged pool allocations now use this 

— NT objects (e.g. reserve objects) can no longer be 
used to store shellcode 

• Requires the system to have enabled DEP 

— If disabled -> ntlExpPoolFlags & 0x800 
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NX Pool Descriptor 


• Windows 8 allocates two pool descriptors per 
non-paged pool 

- Executable and non-executable 

• Separate non-paged NX lookaside lists 

— KPRCB.PPNxPagedLookasideList 

• The kernel calls ntlMmlsNonPagedPooINx to 

determine if a chunk is non-executable 

— Looks up the PTE or the PDE (large page) and checks 
the NX bit 

— E.g. used by the free algorithm 
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Kernel Pool Cookie 


• Used to protect pointers referenced by both 
freed and allocated pool chunks 

— Lookaside lists 
— Process pointers 

• Also used to protect certain cache aligned 
allocations 

• Initialized upon boot (ntllnitializePool) 

• Randomized with several system counters 
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Windows 8 Pool Cookie Initialization 


ULONG_PTR Value; 

KPRCB * Prcb = KeGetCurrentPrcb(); 
LARGE_INTEGER Time; 

KeQuerySystemTime(&Time); 


_rdtsc() A 

// 

tick count 

Prcb->KeSystemCalls A 

// 

number of system calls 

Prcb->InterruptTime A 

// 

interrupt time 

Time.HighPart A 

// 

current system time 

Time.LowPart A 
ExGenRandom(); 

// 

pseudo random number 


ExpPoolQuotaCookie = (Value) ? Value : 1; 


From the Windows 8 Developer Preview 
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ExGenRandom() 


• Generates a pseudo random number 

• Based on the Lagged Fibonacci Generator (LFG) 

- j = 24, k = 55 

— Seeded by boot entropy in the loader parameter block 
(ntIKeLoaderBlock) 

• Used by a number of functions 

— Image base randomization 

— Peb randomization 
— Stack cookie generation 
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Boot Entropy 


• Gathered by winload from six sources 

— OsIpGatherSeedFileEntropy 

— OsIpGatherExternalEntropy 
— OsIpGatherTpmEntropy 
— OsIpGatherTimeEntropy 
— OsIpGatherAcpiOemOEntropy 
— OsIpGatherRdrandEntropy 

• The latter uses the RDRAND instruction 

— New PRNG introduced in Ivy Bridge CPUs 
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Process Pointer Attack 


Address of executive process object 
controlled by the attacker 


i 


EPROCESS 


EPROCESS_QUOTA_BLOCK 
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Process Pointer Encoding 


• Windows 8 addresses this attack by XOR 
encoding the process pointer 

— PoolCookie XOR PoolAddress XOR ProcessPointer 

— Also checks if the decoded pointer points into 
kernel address space (ntIMmSystemRangeStart) 

• Checked upon pool free in 

ntlExpReleasePoolQuota 
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Process Pointer Encoding 
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Lookaside Pointer Attacks 


• Lookaside lists are used for fast allocation 

— Does not require pool descriptor locking (fast!) 

— Singly linked 

— Atomic compare and swap 

• In Windows 7, an attacker could overflow into 
a freed chunk and corrupt the lookaside list 

— Control the address of the next chunk on the list 
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Lookaside Pointer Encoding 


• Windows 8 precedes each lookaside pointer 
with a randomized cookie 

— PoolCookie XOR PoolAddress 
— Checked before pool allocation 

• Also used to protect entries on the deferred 
free list 

• Note: No cookie used for protecting pool page 
lookaside lists 
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Lookaside Pointer Encoding 
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Cache Aligned Allocations 


• Pool allocations can be requested to be cache aligned 

— PoolType & 4 (e.g. NonPagedPoolCacheAligned) 

- CPU cache line size indicated by ntlExpCacheLineSize 

• When requested, the pool allocator ensures that a 
suitable cache aligned address is found by increasing 
the number of bytes requested 

— Rounds up to the nearest cache line size + cache line size 

• Favors performance over space usage 

- x86: 0x40 byte request -> OxCO byte allocation 
— Does not bother with returning unused bytes 
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Cache Aligned Allocation Cookie 


• If a cache aligned chunk is returned from the 
freelists/lookasides, the allocator returns immediately 

- The cache alignment pool type (4) is masked away 

— Nothing is done with the exceeding bytes 

• If an unaligned chunk is returned, the allocator returns 
the address at the nearest cache aligned boundary 

- Returned chunk retains the cache alignment pool type 

• In the latter case, the allocator uses the unused pool 
chunk for storing a cookie 

- *UnusedChunk = UsedChunk A PoolCookie 

- Verification is indicated by the pool type (4) on free 
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Cache Aligned Allocation Cookie 


& 


Pool Header 

Pool 

Cookie 

Unused data 

Pool Header 

Used fragment 


Pool cookie protects cache 
aligned allocation 


Allocation is cache aligned 
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Safe Unlinking 


• Introduced in the kernel pool in Windows 7 

• Makes sure that adjacent elements on a 
doubly linked list point to the chunk being 
unlinked 

• Checks were generally made when a chunk 
was unlinked 

— No checks when linking in a pool chunk 
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Safe (Un)linking in Windows 8 


• Performs both safe linking and unlinking 

— When allocating chunks from a free list 

— When freeing chunks to a free list 
• This also includes unused pool fragments 

• Validates Flink/Blink of both pool descriptor 
list entry and the chunk to be allocated 

— Incomplete validation in Windows 7 allowed for 
Flink attacks 
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Safe Unlinking in Windows 8 


Checks Flink of 
free list entry 


Chunk to be 
allocated 


Checks Flink of 
chunk to be 
allocated 



allocated 
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Poollndex Attack 


• Windows 7 didn't check the Poollndex to the 
associated pool descriptor upon pool free 

— Used as array index for looking up pointer 

• An attacker could overwrite the pool index to 
subsequently control the pool descriptor 

— Out-of-bounds entry would reference a null 
pointer 

— Mapping the null page allows control of the pool 
descriptor and where the chunk is inserted 
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Poollndex Attack 
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Poollndex Fix 


• Windows 8 addresses the Poollndex attack by 
checking the value properly before freeing 

— E.g. is Poollndex < ntlExpNumberOfPagedPools 

• Also prevents user processes from mapping 
the null page 
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Summary 


1 Primitive 

Windows Vista 

Windows 7 

Windows 8 (CP) 

Safe Unlinking 

s 

0 

0 

Safe Linking 

0 

0 

0 

Pool Cookie 


Lookaside Chunks 

0 

0 

0 

Lookaside Pages 

0 

0 

0 

PendingFrees List 

0 

0 

0 

Cache Aligned 



0 

Allocations 




Poollndex Validation 

0 

0 

0 

Encoded Process Pointer 

0 

0 

0 

NX Non-Paged Pool 

0 

0 

0 


* Safe Unlinking: Windows 8 (RP) also addresses the ListHeads Flink attack 
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Block Size Attacks 
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Block Size Attacks 


• The pool header is still subject to attacks as no 
encoding is used 

• Some fields can be hard to properly validate 
— How big is a pool chunk really? 

• An attacker can overwrite the block size of a 
chunk to extend a limited overwrite to an n- 
byte corruption 

— BlockSize Attack 
— Split Fragment Attack 
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BlockSize/PreviousSize 


• Used for indicating the size of a block 

• Used by the allocator in coalescing 

— Checks if adjacent chunks are free and merges to 
reduce fragmentation 

• Also used in validation upon pool free 

— FreedChunk.BlockSize == NextChunk.PreviousSize 

— The exception to this rule is when the next chunk 
is on the next page (PreviousSize is null ) 
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BlockSize Attack 


• When a chunk is freed, it is put into a free list 
or lookaside based on its block size 

• An attacker can overwrite the block size in 
order to put it into an arbitrary free list 

• Setting the block size to cover the rest of the 
page avoids the BlockSize/PreviousSize check 
on free 
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BlockSize Attack 



Allocated 


Allocated 


Free 


Overwrites the 
BlockSize of an 
allocated chunk 


Frees chunk with the 
new block size 


Allocated 


Allocated 


Allocated 



Corrupts adjacent 
chunk with 
arbitrary data 
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BlockSize Attack Steps 


• Corrupt the block size of an in-use chunk 

— Set it to fill the rest of the page 

• Free the corrupted pool chunk 

— Allocator puts the chunk in the free list/lookaside 
for the new size 

• Reallocate the freed memory using something 
controllable like a Unicode string 

— Arbitrary pool corruption 
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Split Chunk Pool Allocation 


• When requesting a pool chunk, the allocator 
scans the free lists until a chunk is found 

— If larger than requested, splits and returns the 
remaining bytes 

• A good amount of sanity checking 

— Validates the Flink/Blink of the chunk to be allocated 
— Validates the Flink/Blink of the free list entry 
— Validates the pool index for the allocated chunk 

• No validation on block size 
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Split Fragment Attack 


• Enables an attacker to extend a 3 byte (semi- 
controlled) overwrite into a n-byte pool 
corruption 

— Targets the BlockSize of chunk in a pool descriptor 
free list 

• If BlockSize is set to a larger value, the 
remaining bytes are returned to the allocator 
— Can free fragments of in-use memory 
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Split Fragment Attack 




Allocated 


Allocated 

Allocated 


Allocated 


Overwrites the 
BlockSize of a chunk 
on a free list 


BlockSize overwrite 
causes block to overlap 
the next chunk 


In allocating the block, 
the remaining fragment 
is returned 


An attacker can gain 
control of the 
free memory 
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Split Fragment Attack Steps 


• Corrupt the blocksize of a free chunk 
— Set it to something larger 

• When the block is allocated, the allocator 
splits it based on the blocksize value 

— Remaining fragment is returned to the free list 

• Reallocate the freed memory using something 
controllable like a Unicode string 

— Arbitrary pool corruption 
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Conclusions 
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Determinism 


• Unlike the Windows 8 heap, the kernel pool 
remains highly deterministic 

— Biased towards efficiency, e.g. in the use of 
lookaside lists for which no locking is required 

• Allows an attacker to very accurately 
manipulate the state of the kernel pool 

• Because of this, attacks on pool content is a 
likely attack vector on Windows 8 
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Block Size Attacks 


• Block size attacks rely on pool determinism 

— Reducing it could reduce feasibility 

• Some block size attacks can be addressed by 
improving the validation 

— E.g. check if the block size of a chunk held by a 
free list is of the expected size upon allocation 
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User Land Closing Notes 


• Windows 7 Exploitation tech has been 
addressed in Windows 8 

• Determinism is at an all time low 

• That being said, there are still viable attacks 
- _HEAP_USERDATA_HEADER Attack 

• Also, since the LFH is grouped by size, use- 
after-free vulnerability exploitation hasn't too 
drastically 
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Kernel Pool Closing Notes 


• Attacks previously demonstrated on Windows 
7 have (mostly) been addressed in Windows 8 
— Proper safe linking and unlinking 

— Randomized cookies used to protect pointers 

• Pool header is not protected (e.g. encoded) 

— An attacker can overflow into an in-use chunk 
— No need to repair pool structures 

• Pool page lookaside lists are not protected 
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Questions? 
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